The technology described herein relates to the processing of graphics, e.g., for display on a display screen.
As is known in the art, it is common in graphics systems to render objects for display by sub-dividing the surface of each object into a number of similar basic components (so-called “primitives”) to allow the graphics processing operations to be more easily carried out. These “primitives” are usually in the form of simple polygons, such as triangles and quadrilaterals.
The graphics primitives are usually generated by the applications program interface for the graphics processing system, using the graphics drawing instructions (requests) received from the application (e.g. game) that requires the graphics output.
Each primitive at this stage is usually defined by and represented as a set of vertices. Each vertex for a primitive has associated with it a set of data (such as position, colour, texture and other attributes data) indicating the properties of the primitive at the vertex. This data is then used, for example, when rasterising and rendering the primitives in order to generate the desired output of the graphics processing system.
Once primitives and their vertices have been generated and defined, they can be processed by the graphics processing system, in order, for example, to display the object that they relate to.
One way to display the surface of an object more accurately and therefore realistically is to increase the number of primitives and vertices used to represent the object. However, sometimes this additional information may not be needed, for example if the object is being viewed from far away or its surface is at a shallow angle to the viewer, such that finer detail in the surface geometry will not be visible in the rendered output, even if it is generated (rendered). In such circumstances, it is a waste of processing resources to process a large number of primitives representing the finer detail of the object.
It is known therefore to represent the surface geometry of objects with larger “patches”, and to then tessellate additional primitives within a patch in the graphics processing pipeline, if required, in order to display a finer level of detail of the object. (As is known in the art, a “patch” is a graphical entity that represents some or all of an object to be displayed (rendered)). This process is known as “tessellation”, and is present in, for example, modern versions of OpenGL and Direct3D.
There are three common types of tessellation: triangular, quadrilateral and isoline. As will be explained more fully below, the technology described herein is particularly concerned with triangular tessellation, which is often the most complex of the three.
FIG. 1 depicts a tessellation stage 10 as implemented in OpenGL and Direct3D, which includes two shader stages 11, 13 and a fixed-function primitive generator or tessellator 12. The hull shader (using Direct3D terminology) or control shader (using OpenGL terminology) 11 is operable to receive a patch (e.g. from upstream stages of the graphics processing pipeline), and to, inter alia, calculate a set of “tessellation levels”. (As is known in the art, the control shader 11 may also modify the patch in some way.) The tessellation levels define the level of tessellation required, and thus the number of additional output primitives that will be generated by the tessellation process.
The tessellation levels are passed to the primitive generator 12, which operates to tessellate a domain to the required degree. As is known in the art, the primitive generator 12 operates on an abstract representation or domain (i.e. not on the patch) (the tessellated domain is then mapped to the patch).
In the case of triangular tessellation, a triangular domain is tessellated into a plurality of triangular tessellation primitives. FIG. 2 shows an example of a triangular domain that has been tessellated. In this case, the primitive generator 12 operates to divide up the triangular domain into smaller triangular tessellation primitives, where the number of tessellation primitives depends on the tessellation levels.
The tessellation levels for a triangular domain comprise an inner tessellation level, IL0, which effectively defines the number of tessellation primitives required for the inner part of the triangular domain, and three perimeter tessellation levels, OL0, OL1, OL2, i.e. one for each edge of the triangular domain, which (together with the inner tessellation level) effectively define the number of tessellation primitives required for the outer part of the triangular domain. These are depicted in FIG. 3. (As used herein, “outer” tessellation primitives are those tessellation primitives that have a vertex on the perimeter of the tessellation domain, and “inner” tessellation primitives are those tessellation primitives that do not have any vertices on the perimeter of the domain. Similarly, “outer” output primitives are those output primitives that correspond to (are derived from) the outer tessellation primitives, and “inner” output primitives are those output primitives that correspond to (are derived from) the inner tessellation primitives.)
The set of tessellated primitives is defined by a set of tessellation coordinates (i.e. points within the triangular domain at the corners of the tessellation primitives), and information defining the connectivity between the tessellation coordinates (i.e. how the tessellation coordinates are to be “joined up” to produce the set of tessellated primitives). This information is calculated by the primitive generator 12.
The domain shader (using Direct3D terminology) or evaluation shader (using OpenGL terminology) 13 receives the output patch from the control shader 11 as well as the tessellation coordinates from the primitive generator 12, and then operates to map the tessellation coordinates onto the patch, i.e. so as to calculate positions of vertices for the output primitives (that are being tessellated) within the patch.
A downstream primitive assembly stage 20 assembles the output primitives using the calculated positions from the domain or evaluation shader 13 and the connectivity information from the primitive generator 12, and then passes the assembled output primitives to further downstream stages of the graphics processing pipeline for further processing, such as rasterisation and rendering, etc., in the usual manner.
In graphics processors, e.g. in lower power and portable devices, it is generally desirable to try to reduce the amount of processing required to generate, e.g. an image for display, so as to reduce the power consumption of the device.
The Applicants believe that there remains scope for improvements to techniques for processing graphics data, and in particular to arrangements where tessellation is provided and used.